The present invention relates to Enterprise JavaBeans (EJB) and more particularly to the provision of a new type of EJB container. (Enterprise JavaBean and EJB are registered trade marks of Sun Micrsosytems Inc.)
Client/Server computing first became fashionable in the 1960""s as a good method of providing many users of small machines (clients) access to data maintained by large systems (servers), the data being maintained in a database. A typical client/server architecture is one in which the client accesses the server through middleware. In this architecture the client is fairly simple and uses applications that run in a server and the middleware handles the complexities of, for example, client/server communication and transaction management. This enables the application writer to concentrate on client and application functionality whilst the middleware takes care of the rest. However, one problem that developed in this architecture was that many middleware products came to the market each providing different functions and different interfaces to those functions. As a result client and application code had to be written to interface with a particular middleware product and could not easily be ported between different middleware products. Further the clients written for one middleware product could not access applications written for a different middleware product.
In order to solve this problem the middleware industry started to look into specifying a standard middleware architecture and interface. There have been several attempts at this and one such attempt was the Common Object Request Broker Architecture (CORBA) which was first published in 1991. However whilst CORBA has been successful and implemented by several middleware products it has been largely superseded by Enterprise JavaBeans which has been built on the success of JavaBeans, Enterprise JavaBeans basically providing applications as JavaBeans in a distributed client/server environment.
The first EJB specification (1.0) was published in March 1998 and was the culmination of several years work between Sun Microsystems Inc. and partner companies, such as IBM, Oracle and Hewlett Packard. From this date there have been many implementations of EJB server products and much has been written about the subject. Indeed most aspects of EJB could now be considered well known and well researched by the those skilled in art. Also the specification of EJB has been improved and extended and recently an new specification, EJB 2.1, was issued as a final draft in June 2002.
A fundamental concept of the EJB Architecture is the EJB Container. An EJB container runs in a server (EJB Server) and a JavaBean (EJB Component) runs in the EJB Container. The EJB specification specifies an interface and services that an EJB Container must provide to both the EJB component and a client (EJB Client) of that EJB component. In this architecture the middleware providers provide an EJB container implementation, conforming to the specified interface and services, for the software platform(s) of their choice. This enables an EJB Client and an EJB Component to be written which can run in, and communicate with, an EJB container implemented by any middleware provider.
The EJB specification specifies containers for 3 different types of EJB Components (beans) and, for each type, a contract (set of interfaces) between the EJB Component and EJB container. The 3 types of EJB Components are known as session beans, entity beans and message driven beans. Session and Entity beans were defined in the first EJB specification and message driven beans are a more recent addition. At a basic level session beans: execute on behalf of a single client; are short lived; do not survive an EJB server crash; can survive several client request; can have a state; and can access shared data in a database. Entity beans: can execute on behalf of many clients; are long lived; are recovered in the event of an EJB server crash; have a key by which they can be found; and tend to represent data in a database. A message driven bean: is not accessed by a client; acts as a message listener by receiving messages, from multiple clients, for processing; does not retain data; and may, for example, pass the message to an entity or session bean for processing. Note that because each EJB Component type has a different contract with its container, an implemented session bean, for example, cannot be run as an entity bean because it will not provide all of the interfaces which the container expects to be able to call on an entity bean. It can thus be seen that, according to its type, an implementation of an EJB Component must provide specified interfaces and observe specified behaviour characteristics, in order to fulfill its contract with the container.
Associated with each EJB Component, regardless of its type, is a deployment descriptor. The deployment descriptor contains details of the EJB Component, such as its bean name, class, remote interfaces, type (session, entity or message driven), and other execution requirements such as its transactional and security requirements. It is thus through the deployment descriptor that a container discovers the bean type of an EJB Component. The container is then responsible for assuring that the execution requirements specified in the deployment descriptor are satisfied before a method request or message is passed to the EJB Component for processing.
However, whilst this provides reasonably flexible support for EJB Components and their clients, despite the fact that the EJB specification is the product of a committee of many engineers from many leading companies, the specification is somewhat rigid in that few bean types are supported. As a result if there is a requirement to implement an EJB Component which does not follow the behaviour pattern of one of the defined bean types it either cannot be supported by an EJB Container, or has to be implemented as multiple, interdependent, EJB Components of different types.
Accordingly the present invention provides a more flexible EJB container which permits easy definition an EJB component that observes a behaviour pattern which is not typical of session, entity or message driven bean types. In this flexible EJB container, behaviour characteristics normally fixed by the bean type of the EJB component, such as passivation policy, usage, recoverability, and relocatability can be separately defined for each EJB component.
According to a first aspect the present invention provides an EJB container which provides an execution environment for an EJB component, the EJB container supporting a set of behaviour patterns for the component including: single user access or multiple user access; transient or persistent data content; passivation never, anytime, or outside of a transaction; and relocatable to another server or not; wherein, a subset of the set of the behaviour patterns is separately selectable for the EJB component based on attributes associated with the component.
According to a second aspect the present invention provides a method for an EJB container to provide an execution environment, in an EJB server, for an EJB component, the method comprising the steps: reading a plurality of attributes associated with the EJB component; and operating on the EJB component in accordance with the attributes; wherein the attributes define a set of behaviour patterns for the component including: single user access or multiple user access; transient or persistent data content; passivation never, anytime, or outside of a transaction; and relocatable to another server or not; and wherein, a subset of the set of the behaviour patterns is separately selectable for the EJB component.
According to a third aspect the present invention provides a computer program product comprising instructions which, when executed on a data processing host, cause the host to carry out a method of the second aspect.